1. The Field of the Invention
The present invention relates to software development technology. More specifically, the present invention relates to mechanisms for testing an object to identify call sequences that result in thrown exceptions.
2. Background and Related Art
Computers have revolutionized the way we work and play. There are an enormous variety of functions and applications that may be implemented by a general purpose computing system in response to the execution of a software application. The utility and functionality of the computing system does, however, rely on the proper coding of the source code that was compiled or interpreted into the binary instructions that are actually executed by the processor. If there is a coding error, this will often result in a deviation from expected functionality.
Extraordinary efforts are currently in place to reduce the number of unexpected functionality deviations in many software programs before and after the software application is shipped to market. However, the creativity of software programmers and designers has led to increasingly complex and powerful software applications. As the complexity of the software application increases, so often does the number of lines of source code needed to generate the software application.
One way of drafting source code in a more organized manner is to use object-oriented programming to cause run-time objects to be generated in memory. These objects have methods associated with them. For example, an object of a particular class called “File” may have a number of methods associated therewith that allow operation on a file. For example, appropriate operations for an object of class “File” may be to open, read, write, close, or check status of the file. Each of these methods may have zero or more permitted parameters associated therewith. For example, the “read” method may include parameters to express how many bytes of the file to read, and/or where to start reading from, and the like. The method with specific parameters is often termed as an “operation”. Similarly, a method having zero parameters is also often termed an “operation” even without parameters. Objects also often have associated data. In the file object example introduced above, the file itself (plus potentially some related data often termed “metadata”) may be the object data.
Although object-oriented programming has provided significant organization to the programming task, inevitable human errors will be introduced into at least early versions of the source code. In order to reduce performance deviations of the software application, it is common to test the software application to identify any performance deviations. In particular with object-oriented programming, one may also test the proper operation of an individual object.
Even during normal and proper operation of an object, the object may encounter a situation that it cannot address. A particular sequence of operations (also called a “call sequence”) may result in such a situation. For example, suppose that after a file object is constructed, one calls the following call sequence in this order as expressed in pseudocode: open(filename), close(filename), write(filename) . . . . The file object will not be able to implement the write operation since the file needs to be open in order to write to it, and since the file was just closed in the previous operation. Call sequences that lead to the object being unable to implement an operation of the call sequence are referred to herein as “invalid call sequences”.
When such errors occur due to an invalid call sequence, the object “throws an exception.” This means that the object notifies the runtime environment that an error has occurred and the exception is displayed and/or noted for future reference. There are typically different exceptions for different detected errors. A particular exception type may correspond to a particular one or more methods of the object.
For example, the open method of the file object may have a “file not found” exception to describe that the file cannot be opened because it was not found. The read (or write) method of the file object may have a “file read” (or “file write”) error to indicate that although the file is open, something about the read (or write) operation has failed. The read (or write) method of the file object may also have a “file closed already” error to indicate that the file is closed and thus cannot be read (or written to). The close method of the file object may have a “file closed already” error to indicate that the file is already closed, and thus cannot be closed again. The check status method of the file object may have a “file not open” exception to indicate that the status of the file cannot be accessed since the file is not open.
The throwing of the proper exception allows the programmer to determine why proper operation was not obtained. If an exception is not thrown at the appropriate time, the object may continue operation for one or more further operations before throwing an unexpected exception that is less representative of the original problem. Accordingly, it is important that the object throws the proper exception in response to a corresponding detected error. One aspect of testing software applications is to make sure that the object throws the right exception in response to an invalid call sequence.
One conventional method of doing this is to have a human tester manually generate an invalid call sequence, execute the call sequence again the object, verify that the correct exception was thrown, and then repeat the process for other invalid call sequences. This can be quite time consuming since it relies on the imagination and effort of the tester to come up with potential invalid call sequences. In addition, the set of invalid call sequences that the tester comes up with can be incomplete despite valiant efforts of the tester. Accordingly, what would be advantageous are mechanisms for testing of an object to detect invalid call sequences in a more automated manner.